Okay, let's do some checkpoint...
After iterating on the frontend implementation and validating the behavior against real deployments (thanks for the reviews, by the way), I converged on a slightly different approach than the one initially proposed in the issue.

Why approach evolved

My initial idea (described in the issue) relied on a dedicated useBadgeRegistryVersion hook, and version detection used as a prerequisite for both reads and writes.

While conceptually sound, testing this against real registries surfaced two practical issues:

1. Multiple read pipelines (version hook + badge list) caused duplicated RPC calls and refetch storms.

2. ABI ambiguity during multicalls made heuristic-based detection (due to length checks) unreliable in practice.

The final solution favors determinism, minimal RPC usage, and real on-chain signals over architectural purity.

Final architecture (implemented in my last commit)

1. Single read pipeline
   All badge reads now go through a single hook:
   totalBadges → version probe → multicall
   This removes duplicated calls and guarantees a stable RPC budget.

2. Probe-based version detection (data-driven)
   Instead of a separate version hook, version detection is integrated directly into useGetBadges:

If `totalBadges === 0`
Return []

No probe, no multicall, no version assumption

Otherwise:

• Run a single probe: getBadgeAt(0) using the V2 ABI
• If it decodes successfully → ABI V2
• If it fails with a decode error only → ABI V1
• Any other error is surfaced normally

This avoids heuristics, avoids address assumptions, and relies purely on observable contract behavior.

3. ABI selection is explicit and strict

• V1 → bytes32ToString
• V2 → bytesToString
• No length-based detection

No silent fallback on non-decode errors

4. Defensive query defaults
   To prevent RPC saturation, I've added defensive QueryClient defaults:

• no refetch on focus / reconnect / remount
• limited retries
• controlled cache lifetime

This ensures predictable behavior even under frequent navigation.

In long-term :

• Works with both existing registries without assumptions

• Deterministic and observable behavior

• Minimal RPC footprint

• Easy to remove once V1 is fully deprecated

The previously introduced useBadgeRegistryVersion hook is no longer needed with this approach and has been removed.

I think this approach is closer to our usage and should behave robustly in practice.

Let me know what you're thinking about.
Happy to adjust or extend this if you’d like to.

Added inline TODOs to clearly mark the temporary V1/V2 BadgeRegistry retro-compat code paths.
Cleanup is tracked separately in #160 and will be handled once the V2 redeploy is complete.

Did you test it with v1 deployment? I can't seem to make it work with a v1 contract (try 0xc142ab6b4688b7b81cb4cc8b305f517bba3bfd25)

I tested against the v1 deployment as well.

I ran locally with:

• PUBLIC_BADGE_REGISTRY_ADDRESS=0x94f5F12BE60a338D263882a1A49E81ca8A0c30F4
• PUBLIC_BADGE_REGISTRY_ADDRESS=0xc142ab6b4688b7b81cb4cc8b305f517bba3bfd25

In both cases the UI loads fine on my side.

If it still fails for you, could you please share the exact page/action that fails and any console error or failing network call?
Happy to help reproduce if you paste the stacktrace / failing call.

Not yet 🙂 I’m going to test the create flow against the v1 deployment and dig into it. I’ll get back with findings shortly.

Updating after further testing.

I’ve now tested the full createBadge flow against both existing Amoy V1 deployments:

0xc142ab6b4688b7b81cb4cc8b305f517bba3bfd25 (older V1)
0x94f5F12BE60a338D263882a1A49E81ca8A0c30F4 (current registry in use, still V1)

In both cases, on my side:

/badges loads correctly
existing badges are displayed
createBadge succeeds without revert

The current implementation detects the ABI on-demand, based on observable on-chain behavior, and routes the write with the correct signature before sending the transaction.
This avoids both ABI-mismatch reverts and any RPC refetch storms.

The frontend should therefore remain fully retro-compatible with V1 while being ready for the upcoming V2 redeploy.

Unless you’d like a different behavior or structure, I think this is ready to merge.
Happy to iterate if you see any edge case I may have missed.

Edit (1 hour later ): I’m now intermittently hitting an Internal JSON-RPC error again while re-running the same flow.
At this stage it smells more like a flaky RPC / provider issue (rate limiting, transient node failure) than a deterministic ABI or frontend bug... unless the RPC gods (or my last commit) decided otherwise 😄
Still investigating and will report back with concrete repro details.

Separately, once this is fully settled, I’ll do a small follow-up cleanup pass on the previous commit (pure refactor / readability only, no behavior changes).

I pushed a small refactor (helpers extraction only). No behavior change intended.
I also instrumented the flow locally (debug-only) : eth_call, simulateContract, and estimateGas succeed on both Amoy V1 registries, which strongly suggests ABI detection + args are correct and the call is valid at EVM level.
When I occasionally hit Internal JSON-RPC error, it appears intermittent and more consistent with RPC/provider flakiness during the send/estimation path than a deterministic contract revert.
I'm avoiding additional write tests to not pollute the deployed registries.

Optional UX follow-up : we could treat Internal JSON-RPC error / transient provider failures as a retryable class and surface a clearer message to users (eg. "RPC/provider hiccup. Please retry in a few seconds or switch RPC") possibly with a simple Retry action.

@V-Vaal

Optional UX follow-up : we could treat Internal JSON-RPC error / transient provider failures as a retryable class and surface a clearer message to users (eg. "RPC/provider hiccup. Please retry in a few seconds or switch RPC") possibly with a simple Retry action.

There already was an error message. What do you see now?